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command is received by the service broker and forwarded to the at least one connected 
device. 

Claim 3 1 (currently amended) The service broker [according to] set forth in 
claim 1, wherein the first communication module is capable of handling a device identifier. 

Claim 32 (currently amended) The service broker [according to] set forth in 
claim 1, wherein the first communication module is capable of handling a class of device 
identifiers. 

Claim 33 (currently amended) The service broker [according to] set forth in 
claim [1] 9, wherein the virtual representation comprises a mapped control, group of 
controls, or user interface. 

REMARKS 

Reconsideration of this Application is respectfully requested. Claims 1-33 are 
amended, without prejudice or disclaimer. Claims 1-33 are in this case. 

Initially, the Examiner reminded Applicants of a Patent Office Communication dated 
September 5, 2003 indicating that the request to correct inventorship under 37 C.F.R. § 
1.48(a) is deficient. According to the Examiner, a Declaration by each actual inventor or 
inventors listing the entire inventive entity has not been submitted. He explains that the new 
Declaration submitted on October 9, 2002 is not signed by Babak Rezvani and Jack Chen, 
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and that the previous Declaration does not alleviate this discrepancy because such does not 
include inventor Edward Kalin. 

As for the Specification, the Examiner objected to the Abstract under MPEP § 
608.01(b) for allegedly being too long (i.e., more than 150 words). Correction was then 
required by the Examiner. The Examiner reminded Applicants of the proper language and 
format for the Abstract. 

In response, Applicants respectfully state that a new Declaration bearing signatures of 
all of the inventors will follow in due course. In addition, the Abstract is amended in 
accordance with the Examiner's objection. Withdrawal of the Examiner's objection is, 
therefore, respectfully requested. 

s|e $ $ i|e s(e 

Next, the Examiner rejected claims 11-14, 18, 27-28 and 30 under the judicially 
created doctrine of obviousness-type double patenting as being unpatentable over some 
claims of U.S. Patent No. 6,621,827. More particularly, claim 2 of U.S. Patent No. 
6,621,827 allegedly contains each and every element of Applicants' claim 1 1 and, as such, 
anticipates that claim. The Examiner also takes the position that claim 3 of U.S. Patent No. 
6,621,827 teaches each element of Applicants' claim 12 and, therefore, anticipates that claim. 
With respect to claim 13, the Examiner argues that claim 4 of U.S. Patent No. 6,621,827 
recites each and every element of Applicants' claim 13 and, as such, anticipates claim 13. As 
for claim 14, says the Examiner, claim 5 of U.S. Patent No. 6,621,827 teaches every element 
of Applicants' claim 14 and, hence, anticipates that claim. 
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Furthermore, the Examiner finds that claim 6 of U.S. Patent No. 6,621,827 recites 
each element of Applicants' claim 18 and, accordingly, anticipates that claim was well. 
Regarding claim 27, the Examiner takes the position that claim 7 of U.S. Patent No. 
6,621,827 teaches every element of Applicants' claim 27 and, as such, anticipates the claim. 
Applicants' claim 28, the Examiner continues, is anticipated by claim 8 of U.S. Patent No. 
6,621,827 and, thus, anticipates claim 28. Finally, the Examiner states, in connection with 
Applicants' claim 30, that claim 9 of U.S. Patent No. 6,621,827 contains each and every 
element of claim 30 and, therefore, anticipates that claim. 

The Examiner notes, however, that a timely filed terminal disclaimer in compliance 
with 37 C.F.R. § 1 .32 1(c) may be used to overcome an actual or provisional rejection based 
on a non-statutory double patenting ground provided the conflicting application or patent is 
shown to be commonly owned with this Application, citing 37 C.F.R. § 1.130(b). 

Thereafter, the Examiner objected to claim 1 1 explaining that each limitation ending 
with a semicolon should be on a separated line for clarity. Appropriate correction was then 
required by the Examiner. 

A Terminal Disclaimer is filed herewith to obviate the Double Patenting rejection set 
forth above. Also, claim 11 is amended for clarity, in accordance with the Examiner's 
comments. Accordingly, withdrawal of the Examiner's objection and double patenting 
rejection is considered appropriate. 

Next, the Examiner rejected claims 30 and 33 under 35 U.S.C. § 1 12, second para- 



13 

graph, for indefiniteness. Specifically, the Examiner explains that there is insufficient ante- 
cedent basis for the limitation "the command" on line 2 of claim 30. The Examiner also 
states that there is insufficient antecedent basis for the limitation "the virtual representation" 
on line 1 of claim 33. 

In response, Applicants have amended claim 30 to depend from claim 18, and claim 
33 to depend from claim 9 for proper antecedent basis, as requested by the Examiner. 
Withdrawal of the Examiner's rejection under § 1 12 is, thereby, requested. 

In addition, the Examiner rejected claims 1-5, 8 and 31-32 under 35 U.S.C. § 102(b) 
as being anticipated by Page et al., U.S. Patent No. 5,329,619. In particular, regarding claim 
1, the Examiner takes the position that Page et al. teach a service broker 14 (FIG. 2 and the 
Abstract) for processing data from a data network (referencing managing of service requests 
from, and responsive services provided by, a plurality of clients and servers [communication 
via LAN or WAN] in the heterogeneous environment - the Abstract, column 4, lines 23-41 
and column 6, lines 19-36) including at least one data source (citing server 12, FIG. 2 and the 
Abstract) comprising: (i) a first communication module (i.e., initialization routine) for 
initiating communication with a moderator (citing manager such as communication manager/ 
virtual store manager) and adapted to receive data from the moderator (i.e., establishing the 
broker environment, obtaining the necessary storage, initiating various control blocks, queues 
and tables, setting up a virtual address entry structure for the virtual storage manager, etc. - 
column 16, lines 26-39 and column 28, lines 41-52); (ii) a second communication module 
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(i.e., dispatcher) for sending data to at least one of the data source and the moderator (i.e., 
manager, namely, activating worker components and various managers and passing request 
to the worker components for processing - column 16, lines 45-66); (iii) a service-action 
module (i.e., worker components) for processing the received data and for performing a task 
based on the processed data (i.e., processing participant requests - column 16, lines 40-44); 
and (iv) an export module (namely, part of worker components) in communication with the 
service-action module and for publishing data (i.e., sending data) based at least in part on the 
performed task to the data network (i.e., worker components consist of all routines that deal 
with the various functions such as register, send, receive, etc. - column 16, lines 40-44). 
This, the Examiner asserts, suggests that after receiving data requests, worker components 
process the received data requests and then store and send/forward data request (i.e., publish 
data) to the server (data source - FIG. 6, the Abstract and column 16, lines 40-44). 

Regarding claim 2, the Examiner argues that Page et al. teach that the published data 
is published to at least one of the data source and the moderator (i.e., after receiving data 
requests, worker components process the data received data requests and then store and 
send/forward data request (publish data) to the serer (data source) - FIG. 6, the Abstract and 
column 16, lines 40-44). With reference to claim 3, the Examiner asserts that Page et al. 
further teach a moderator that includes a data store (i.e., managing the available storage and 
ensuring efficient use of the available storage in a changing environment - column 28, lines 
47-52) and a first communication module receiving data from the data store (i.e., obtaining 
the necessary storage - column 1 6, lines 26-39). The Examiner further finds that Page et al. 
disclose a data store storing data received from the at least one data source as set forth in 



15 

claim 4 (i.e., maintaining relevant information and parameters in several links data structure 
including control blocks, tables and queues - Figs. 6, 7G and 8, column 19, line 59 to column 
20, line 2, and column 45, line 64 to column 46, line 17). 

Next, the Examiner takes the position that Page et al. further teach that the data store 
is a command queue (i.e., message queues) and that the data received from the data source is 
a command intended to be processed by the service-action module (namely, a worker 
component - i.e., a worker queue structure that is used to pass requests to the worker 
components and worker components responsible for the processing of participant requests 
dealing with various functions such as register, send, receive, etc. - column 16, lines 40-44 
and 66-67). The first communication module, says the Examiner, receives the command 
from the queue (i.e., maintaining relevant information and parameters in several links data 
structure including control blocks, tables and queues and message queues arranged as a 
linked list like the control blocks - FIGS. 6, 7G and 8, column 19, line 59 to column 20, line 
2, column 23, lines 58-60 and column 45, line 64 to column 46, line 17). 

Turning now to claim 8, the Examiner asserts that Page et al. teach a performed task 
that comprises communicating a command based at least in part on the processed data to a 
device connected to the service broker (i.e., worker components responsible for the 
processing of participant requests dealing with various functions such as register, send, 
receive, etc. - FIGS. 6, 7G and 8, column 16, lines 40-44). Page et al. additionally teach, the 
Examiner continues, a first communication module (i.e., initialization routine) capable of 
handling a device identifier as set forth in Applicants' claim 3 1 (i.e., establishing the broker 
environment, obtaining the necessary storage, initiating various control blocks, queues and 
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tables, setting up a virtual address entry structure for the virtual storage manager, etc. - 
column 16, lines 26-39 and column 28, lines 41-52) as well as creating service control block 
(SCB) and conversation control block (CCB) including IDs (the Examiner referencing 
column 19, line 66 to column 20, line 65). 

As for claim 32, the Examiner takes the position that Page et al. discloses a first 
communications module (i.e., initialization routine) capable of handling a class of device 
identifiers (namely, establishing the broker environment, obtaining the necessary storage, 
initiating various control blocks, queues and tables, setting up a virtual address entry 
structure for the virtual storage manager, etc. - column 16, lines 26-39 and column 28, lines 
41-52 - and creating service control block (SCB) and conversation control block (CCB) 
including IDs (i.e., column 19, line 66 to column 20, line 65). Moreover, the Examiner 
indicates that such is a service broker system for clients and servers operating in a 
heterogeneous computing environment (citing the Abstract and column 1, lines 9-11) and, 
thus, suggests that the first communication module (i.e., initialization routine) is capable of 
handling a class of device identifiers (i.e., multiple devices wherein each device has an ID). 

Thereafter, the Examiner rejected claims 6-7 under 35 U.S.C. § 103(a) as obvious 
and, therefore, unpatentable over Page et al. in view of Jeske, U.S. Patent No. 5,974,443. 
According to the Examiner, with respect to claim 6, the Examiner acknowledges that Page et 
al do not explicitly teach the first communication module in communication with the 
moderator via the HTTP protocol. However, says the Examiner, Page et al. does suggest the 
use of a client/server environment with TCP/IP protocol (citing column 1, lines 8-63). The 
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Examiner then looks to Jeske which, he says, is in the same field of client/server network 
environment endeavors, and discloses the use of HTTP protocol as communication protocol 
between client server (referencing FIG. 1 and column 2, line 54 to column 3, line 7). The 
Examiner concludes that it would have been obvious to one having ordinary skill in the art at 
the time the invention was made to incorporate implementation of HTTP protocol for 
communicating between client and server, as allegedly set forth by Jeske , into the system of a 
service broker for processing data between client and server in a data network, as purportedly 
disclosed by Page et aL in order to enhance the system by extending the use of transaction 
and accessing information over the World Wide Web environment with a simple 
request/response command like URL. 

With regard to claim 7, the Examiner admits that Page et al. does not explicitly teach 
the data source communicating with the moderator via the HTTP protocol. However, he 
asserts that Page et al. do suggest the use of a client/server environment with TCP/IP 
protocol (citing column 1, lines 8-63). He then looks to Jeske as, again, being in the same 
field of client/server network environment endeavor, and as disclosing the use of HTTP 
protocol as communication protocol between client and server (citing FIG. 1 and column 2, 
line 54 to column 3, line 7). The Examiner concludes that it would have been obvious to one 
of ordinary skill in the art at the time the invention was made to incorporate implementation 
of HTTP protocol for communicating between client and server, purportedly set forth by 
Jeske , into the system of a service broker for processing data between client and server in a 
data network, as allegedly disclosed by Page et al. , in order to enhance the system by 
extending the use of transaction and accessing information over the World Wide Web 
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environment with a simple request/response command like URL. 

j(e jje >(c $ % 

Furthermore, the Examiner rejected claims 9-11, 18-30 and 33 under 35 U.S.C. § 
103(a) as obvious and, therefore, unpatentable over Page et al. in view of Brackett et aL U.S. 
Patent No. 6,519,632. More particularly, with respect to claim 9, the Examiner admits that 
Page et al. do not explicitly teach at least one of the moderator and the data source 
comprising a virtual representation of the service broker, and wherein the published data 
updates the virtual representation. The Examiner notes, however, that Page et al. do suggest 
the system of a service broker for processing data between client and server in a data network 
(LAN or WAN) (referencing FIGS. 2, 6, 7G, 8 and 23 and the Abstract) wherein the 
moderator is a manager such as communication manager/virtual store manager and the data 
source is server (citing FIGS. 2, 6, 7G, 8 and 23, the Abstract, column 16, lines 26-67 and 
column 28, lines 41-52). 

Accordingly, the Examiner looks to Brackett et al. which, he says, is in the same field 
of client/server network environment endeavor and is directed to virtual representation of 
data configured and retrieved by the mapping manager for sending to the display monitor 
(citing FIGS 2, 3, 5, 6 and 8, column 5, line 60 to column 6, line 5, and column 8, line 59 to 
column 9, line 30). The Examiner concludes that it would have been obvious to one of 
ordinary skill in the art at the time the invention was made to incorporate the implementation 
of virtual representation data in the network, as allegedly disclosed by Brackett et al. , into the 
system of a service broker for processing data between client and server in a data network, 
purportedly set forth by Page et al. , in order to enhance the system by extending the use of 
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transferring data to more than one remote devices for reflection of the network device status 
data on the display (citing column 9, lines 20-30). Thus, the Examiner finds, it would have 
enabled the status information to be easily monitored and remotely updated in real-time. 

With respect to claim 10, the Examiner takes the position that while Page et al. does 
not explicitly teach at least one of the moderator and the data source comprising a virtual 
representation of the connected device, and wherein the published data updates the virtual 
representation, Page et al. suggest the system of a service broker for processing data between 
client and server in a data network (LAN or WAN) (citing FIGS. 2, 6, 7G, 8 and 23 and the 
Abstract) wherein the moderator is a manager such as communication manager/ virtual store 
manager and the data source is a server (referencing FIGS. 2, 6, 7G, 8 and 23, the Abstract, 
column 16, lines 26-67 and column 28, lines 41-52). 

The Examiner then looks to Brackett et al. . as purportedly in the same field of 
client/server network environment endeavor, and for allegedly disclosing virtual represent- 
tation of data configured and retrieved by the mapping manager for sending to the display 
monitor (FIGS. 2, 3, 5, 6 and 8, column 5, line 60 to column 6, line 5, and column 8, line 59 
to column 9, line 30). He concludes that it would have been obvious to one of ordinary skill 
in the art to incorporate the implementation of virtual representation data in the network, 
allegedly disclosed by Brackett et al. , into the system of a service broker for processing data 
between client and server in a data network, as allegedly set forth by Page et al. , in order to 
enhance the system by extending the use of transferring data to more than one remote devices 
for reflection of the network device status data on the display (citing column 9, lines 20-30). 
Thus, says the Examiner, it would have enabled the status information to be easily monitored 
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and remotely updated in real-time. 

Referring now to claim 1 1 , the Examiner believes that Page et al. teach a method for 
transferring data from a data source (i.e., server) to a service broker 14 comprising the steps 
of: (i) providing a data source (i.e., server) and a service broker 14; (ii) providing a 
moderator (i.e., manager such as communication manager/virtual store manager) for 
receiving the data transferred by the data source (i.e., handling all necessary communication, 
obtaining the necessary storage and initiating various control blocks, queues and tables, etc. - 
column 16, lines 26-39 and column 28, lines 41-52); (iii) providing a data store for storing 
data received by the moderator (i.e., managing the available storage and ensuring efficient 
use of the available storage in a changing environment - column 28, lines 47-52); (iv) 
providing a communications module (i.e., dispatcher) for transferring data from the data store 
(i.e., passing requests to the worker components for processing - column 16, lines 45-66); (v) 
transferring data from the data source (i.e., server) to the moderator (i.e., manager such as 
communication manager/virtual store manager - establishing the broker environment, 
obtaining the necessary storage, initiating various control blocks, queues and tables, setting 
up a virtual address entry structure for the virtual storage manager, etc. - column 16, lines 
26-39 and column 28, lines 41-52); (vi) storing the data received by the moderator in the data 
store (i.e., managing the available storage and ensuring efficient use of the available storage 
in a changing environment - column 28, lines 47-52); and (vii) retrieving the data from the 
data store via the communications module (i.e., dispatcher) and forwarding the data to the 
service broker (i.e., activating worker components and various managers and passing 
requests to the worker components for processing participant requests worker components 



21 

consist of all routines that deal with the various functions such as register, send, receive, etc. 
- column 16, lines 40-66). This, the Examiner asserts, indicates that worker components 
process the received requested data forwarded to the broker (namely, bi-directional 
communications between data source (i.e., server) and service broker includes data 
forwarding from the server to the service broker - FIGS. 6, 7G, 8 and 9, the Abstract, and 
column 16, lines 40-44). 

While the Examiner admits that Page et al. do not explicitly teach providing a virtual 
representation of the service broker on the data source, the data sent allegedly being related 
to or associated with the virtual representation, updating the virtual representation when the 
service broker receives the data sent by the data source whereby data is transferred between 
the data source and to the service broker, Page et al. , the Examiner continues, do suggest the 
system of a service broker for processing data between client and server in a data network 
(LAN or WAN) (citing FIGS. 2, 6, 7G, 8 and 23, and the Abstract) wherein the moderator is 
a manager such as communication manager/virtual store manager and the data source is a 
server (making reference to FIGS. 2, 6, 7G, 8 and 23, the Abstract, column 16, lines 26-67, 
and column 28, lines 41-52). 

He then looks to Brackett et al. , alleging it to be in the same field of client/server 
network environment endeavor, and for purportedly disclosing virtual representation of data 
configured and retrieved by the mapping manager for sending to the display monitor (FIGS. 
2, 3, 5, 6 and 8, column 5, line 60 to column 6, line 5, and column 8, line 59 to column 9, 
line 30). The Examiner concluded that it would have been obvious to one of ordinary skill in 
the art at the time the invention was made to incorporate the implementation of virtual 
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representation data in the network, purportedly disclosed by Brackett et al , into the system of 
a service broker for processing data between client and server in a data network, as allegedly 
set forth by Page et al. . in order to enhance the system by extending the use of transferring 
data to more than one remote devices for reflection of the network device status data on the 
display (citing column 9, lines 20-30). Thus, says the Examiner, it would have enabled the 
status information to be easily monitored and remotely updated in real-time. 

Page et aL the Examiner argues, further teaches the data being a command for 
changing the state of the service broker, as set forth in claim 18 (i.e., dispatcher constantly 
monitors the status of all workers and the mangers for changes in status and takes appropriate 
action when a status changes - column 16, lines 56-66). He acknowledges that Page et al. do 
not explicitly teach the virtual representation being updated when the state of the service 
broker is changed, but believes Page et al. suggest the system of a service broker for 
processing data between client and server in a data network (LAN or WAN) (FIGS. 2, 6, 7G, 
8 and 23, and the Abstract) wherein the moderator is a manager such as communication 
manager/virtual store manger and the data source is a server (FIGS. 2, 6, 7G, 8 and 23, the 
Abstract, column 16, lines 26-67, and column 28, lines 41-52). 

The Examiner looks to Brackett et al. for their alleged disclosure of virtual 
representation of data configured and retrieved by the mapping manger for sending to the 
display monitor (FIGS. 2, 3, 5, 6 and 8, column 5, line 60 to column 6, line 5, and column 8, 
line 59 to column 9, line 30). He concluded that it would have been obvious to incorporate 
the implementation of virtual representation data in the network, disclosed by Brackett et al. , 
into the system of a service broker for processing data between client and server in a data 
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network, as allegedly disclosed by Page et aL in order to enhance the system by extending 
the use of transferring data to more than one remote devices for reflection of the network 
device status data on the display (column 9, lines 20-30). Such, the Examiner found, would 
have enabled the status information to be easily monitored and remotely updated in real-time. 

Moreover, according to the Examiner, Page et al. teach (i) that the data sent is a 
command for changing the state of the service broker, as set forth in claim 19 (i.e., dispatcher 
constantly monitors the status of all workers and the managers for changes in status and takes 
appropriate action when a status changes - column 16, lines 56-66); (ii) the moderator and 
the data store being the same entity, as set forth in claim 20 (i.e., moderator = manager such 
as communication manager and virtual store manager wherein virtual store manager manages 
available storage - column 28, lines 41-52); (iii) the data store and the communications 
module being the same device, as in Applicants' claim 21 (i.e., all components being in a 
service broker - column 16, lines 26-67); (iv) the moderator, data store, and the 
communications module being the same entity, according to claim 22 (i.e., all components 
being in a service broker - column 16, lines 26-67); (v) that there are a plurality of data 
stores (i.e., queues), as in claim 23 (namely maintaining relevant information and parameters 
in several links data structure including control blocks, tables and queues - FIGS. 6, 7G and 
8, column 19, line 59 to column 20, line 2, and column 45, line 64 to column 46, line 17); 
(vi) that there are a plurality of service brokers (i.e., multiple brokers), as in claim 24 (citing 
FIG. 23); (vii) a plurality of moderators (i.e., manger such as communication manager/virtual 
store manager - column 28, lines 41-52) and data stores (i.e., queues), set forth in claim 25 
(namely, maintaining relevant information and parameters in several links data structure 
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including control blocks, tables and queues - FIGS. 6, 7G and 8, column 19, line 59 to 
column 20, line 2, and column 45, line 64 to column 46, line 17); (viii) the data source (i.e., 
server) and the service broker being at the same node, as in claim 26 (i.e., server and broker 
being at the same node - FIG. 23); (ix) the data store being a queue of commands (i.e., 
message queues) as provided in claim 27 (namely, maintaining relevant information and 
parameters in several links data structure including control blocks, tables and queues and 
message queues arranged as a linked list like the control blocks - FIGS. 6, 7G and 8; column 
19, line 59 to column 20, line 2, column 23, lines 58-60, and column 45, line 64 to column 
46, line 17); (x) the data transferred from the data store to the service broker being initiated 
by the service broker, according to claim 28 (i.e., obtaining the necessary storage and 
initiating various control blocks queues and tables, setting up a virtual address entry structure 
for the virtual storage manager, etc. - FIGS. 6, 7G and 8, column 1 6, lines 26-39 and column 
28, lines 41-52); (xi) the data being retrieved by specifying a specific device identifier as 
provided by claim 29 (i.e., service control block (SCB) and conversation control block 
(CCB) created including IDs - column 19, line 66 to column 20, line 65); and (xii) at least 
one device connected to the service broker (namely, client or server being connected to a 
service broker - FIG. 2) and wherein the command is received by the service broker and 
forwarded to the at least one connected device, as provided by claim 30 (i.e., request being 
forwarded to the server - FIGS. 5, 7G and 8). 

Regarding claim 33, the Examiner admits that Page et al. does not explicitly teach the 
virtual representation comprising a mapped control, group of controls, or user interface, but 
argues that Page et al. suggests the system of a service broker for processing data between 
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client and server in a data network (LAN or WAN) (citing FIGS. 2, 6, 7G, 8 and 23, and the 
Abstract) wherein the moderator is a manager such as communication manager/virtual store 
manager and the data source is a server (referencing FIGS. 2, 6, 7G, 8 and 23, the Abstract, 
column 16, lines 26-67, and column 28, lines 41-52). 

The Examiner then looks to Brackett et al. (again, allegedly in the same field of 
endeavor) for purportedly teaching virtual representation of data configured and retrieved by 
the mapping manager for sending to the display monitor (citing FIGS. 2, 3, 5, 6 and 8, 
column 5, line 60 to column 6, line 5, and column 8, line 59 to column 9, line 30). He 
concluded that it would have been obvious to incorporate the implementation of virtual 
representation data in the network, purportedly taught by Brackett et al. , into the system of a 
service broker for processing data between client and server in a data network, allegedly 
disclosed by Page et ah , to enhance the system by extending the use of transferring data to 
more than one remote device for reflection of the network device status data on the display 
(citing column 9, lines 20-30). Such, the Examiner determined, would have enabled the 
status information to be easily monitored and remotely updated in real-time. 

Finally, the Examiner rejected claims 12-17 under 35 U.S.C. § 103(a) as being 
obvious and, therefore, unpatentable over Page et al. in view of Brackett et al. and further in 
view of Jeske . First, the Examiner admits that Page et al. and Brackett et al. do not explicitly 
teach that data transfer from the data source to the moderator (or from the moderator to the 
service broker) is performed using the HTTP protocol. He notes, however, that Page et al. 
suggest the use of client/server network environment with TCP/IP protocol (citing column 1 , 
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lines 8-63) and that Brackett et al. suggest the implementation of client/server network 
environment (column 2, lines 44-47). 

The Examiner then looks to Jeske which, he purports, is in the same field of 
client/server network environment endeavor, and allegedly discloses the use of HTTP 
protocol as communication protocol between client and server (referencing FIG. 1 and 
column 2, line 54 to column 3, line 7). He determined that it would have been obvious to 
one of ordinary skill in the art at the time the invention was made to incorporate imple- 
mentation of HTTP protocol for communicating between client and server, as allegedly 
disclosed by Jeske, into the system of a service broker for processing data between client and 
server in a data network, purportedly disclosed by Page etaL and the system of client/server 
network environment, allegedly set forth by Brackett et al. , to enhance the system by 
extending the use of transaction and accessing information over the World Wide Web 
environment with a simple request/response command like URL. 

With reference to claims 14 and 15, the Examiner acknowledges the neither Page et 
al. nor Brackett et al. explicitly teach that such data is transferred using name/value pairs. In 
the Examiner's view, however, Page et al. suggest the use of client/server environment with 
TCP/IP protocol (citing column 1, lines 8-63) and Brackett et al. implies the implementation 
of client/server network environment (citing column 2, lines 44-47) with transferred object 
having attribute information in name/value representation (at column 4, lines 25-36). 

The Examiner then looks to the teachings of Jeske which, the Examiner asserts, is in 
the same field of client/server network environment endeavor, as allegedly disclosing the use 
of HTTP protocol as communication protocol between client and server for accessing a 
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resource by using command URL wherein request (command) is encoded with name/value 
pairs (at column 5, lines 20-45). Accordingly, he found that it would have been obvious to 
one of ordinary skill in the art to incorporate implementation of HTTP protocol for 
communicating between client and server for accessing a resource by using command URL 
wherein request is encoded with name/value pairs, disclosed by Jeske, into the system of 
client/server network environment, purportedly disclosed by Brackett et aL and a service 
broker for processing data between client and server in a data network, allegedly disclosed by 
Page et aL to enhance the system by extending the use of transaction and accessing 
information over the World Wide Web environment with a simple request/response 
command like URL wherein the command can be encoded by using name/value pairs for 
efficiently being sent and easily being identified. 

As for claims 16 and 17, the Examiner admits that neither Page et aL Brackett et al. 
nor Jeske explicitly teach the name/value pair transmitted using a field/value abstraction 
layer. However, the Examiner asserts, Page et al. do suggest the use of client/server network 
environment with TCP/IP protocol (citing column 1, lines 8-63) and Brackett et al. suggest 
the implementation of client/server network environment (at column 2, lines 44-47) with 
transferred object having attribute information in name/value representation (at column 4, 
lines 25-36). 

The Examiner then applies Jeske which, he reiterates, is in the same field of 
endeavor, and discloses the use of HTTP protocol as communication protocol between client 
and server for accessing a resource by using command URL wherein request (command) is 
encoded with name/value pairs and wherein name- value pairs are the field name and the field 
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value of a request (command) (referencing column 5, lines 20-45). He concludes that it 
would have been obvious. to incorporate implementation of HTTP protocol for communi- 
cating between client and server for accessing a resource by using command URL wherein 
request (command) is encoded with set or group of name/value pairs, disclosed by Jeske, into 
the system of client/server network environment, set forth by Brackett et aL and a service 
broker for processing data between client and server in a data network, as provided by Page 
et aL in order to enhance the system by extending the use of transaction and accessing 
information over the World Wide Web environment with a simple request/response 
command like URL wherein command can be encoded by using name/value pairs for 
efficiently being sent and easily being identified. 

Applicants, however, respectfully disagree with the Examiner's reading and applica- 
tion of the cited references. 

First, Applicants' invention relates to a service broker system and method for 
processing data from a data network, namely, interactive monitoring and control of data to 
and from computers and Internet enabled devices of a client/server safety system over the 
Internet. Applicants' scheme delivers data to receivers that is extraordinarily light-weight, in 
terms of processing and hardware requirements, does not require an always-on connection, 
and eliminates safety risks associated with conventional embedded server systems. 

Page et aL on the other hand, describes a "service broker" allegedly for managing 
server requests from, and responsive services provided by, a plurality of clients and servers. 
Such may reside on different hardware platforms and operating systems, have different 
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programming interfaces, and may be connected to computer networks having different 
network architectures and communications protocols. 

While Page et al/ s service broker purports to operate over a network, there is no 
disclosure or suggestion of operation over the Internet or with Internet enabled devices, as 
claimed by Applicants. Nor could Page et al. be read to suggest such an arrangement, we 
submit, as the Patent Application of Page et al. was filed in 1992, years before widespread 
proliferation of the Internet had yet occurred. 

Accordingly, Page et al. , we respectfully submit, simply does not disclose or suggest 
Applicants' invention. 

Second, Brackett et al. relates to a computerized ultrasound imager for transferring 
digital images over a local area network (LAN) to remote devices for archiving and printing 
(i.e., printers, data storage devices, etc.). The imager is programmed with multiple 
configurable DICOM (Digital Imaging and Communications in Medicine) tasks. 

Although this arrangement discusses the transferring of image data to printers and 
storage over a LAN, Brackett et al. neither references the Internet nor is the imager they 
describe applicable to the Internet. 

As for Jeske, while this reference relates to a system and method for distributing 
information and web servers, i.e., over the Internet, via a plurality of interconnected plat- 
forms or nodes, it does not disclose or suggest application of the same to a service broker 
arrangement, as taught by Applicants. More particularly, Jeske does not describe or infer a 
"service broker system for interactive monitoring and control of data to and from computers 
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and Internet enabled devices of a client/server safety system over the Internet", as set forth by 
Applicants' claims. 

***** 

Notwithstanding the foregoing, Applicants have undertaken to amend independent 
claims 1 and 1 1 , without prejudice or disclaimer, to clarify that Applicants' service broker is 
a "system for interactive monitoring and control of data to and from computers and Internet 
enabled devices of a client/server safety system over the Internet". 

Hence, even if Page et aL Brackett et al. and/or Jeske, we submit, were combinable, 
none of these references, whether taken alone or in any combination, disclose or suggest 
Applicants' invention, as claimed. Withdrawal of the Examiner's rejections under §§ 102(b) 
and 103(a) is, therefore, respectfully requested. 

Applicants have made a good faith attempt to place this Application in condition for 
allowance. Favorable action is requested. If there is any further point requiring attention 
prior to allowance, the Examiner is asked to contact Applicants 1 counsel at (212) 768-3800. 

Please charge any additional fees to our firm Deposit Account No. 50-0518. 

Respectfully submitted. 

Dated: November 8, 2004 

Grant E. Pollack, Esq. 
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